home *** CD-ROM | disk | FTP | other *** search
- Path: nntp.teleport.com!sschaem
- From: sschaem@teleport.com (Stephan Schaem)
- Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
- Subject: Re: AB3D II beats Quake....
- Followup-To: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
- Date: 1 Apr 1996 12:43:16 GMT
- Organization: Teleport - Portland's Public Access (503) 220-1016
- Message-ID: <4joj14$ghj@nadine.teleport.com>
- References: <DosA8o.17B@info.uucp> <6538.6658T1031T2526@mbox.vol.it> <4jgn4o$l2b@hell.team17.com> <4jk515$q3l@nadine.teleport.com> <4jkdpu$1o6@hell.team17.com>
- NNTP-Posting-Host: julie.teleport.com
- X-Newsreader: TIN [version 1.2 PL2]
-
- Stefan Boberg (boberg@team17.com) wrote:
- : sschaem@teleport.com (Stephan Schaem) wrote:
- : >Stefan Boberg (boberg@team17.com) wrote:
- : >: bizzetti@mbox.vol.it (Fabio Bizzetti) wrote:
-
- : >: >Do you think that F1GP-II, Quake & co. are written in ANSI C++??? =)))
-
- : >: Yes. They are. And better because of it.
-
- : > The problem is slow part are in c++, could be anything really.
-
- : ?? I'm not sure if I follow you. Anyway, the bulky code that
- : executes infrequently is written in C/C++ in Quake and almost
- : certainly in F1GP-II.
-
- I only wanted to clear that those game are not 100% c++. because
- they are suposed to be game that require hi eficiency routine,
- and c++ doesn't fit in this picture.
-
- : > The part that matter are in ASM...
-
- : In Quake's case, only the scan-conversion, and some other small
- : bits. Makes perfect sense.
-
- I think they should do more then just the scan conversion...
- Right now ID is still working on the game, my guess is by the time
- its released they will have rewriten more C part on the rendering engine
- in 486 and pentium assembly.
-
- Something that I recall is that ID said quake was slow on 486 because
- it uses floating point optimization for the pentium, and told they them
- would optimize it for the 486. now, was this optimization planeed as a
- compiler switch? :) where those floating point operation done during
- the scanline rasterization (bad pratice). My guess is that if really
- float slow down quake on 486 is that otherpart of the engine need to
- be optimized aside the scan-conversion.
-
- BTW do you see scan-conversion as the scan rendering loop or the
- full rasterizing routine?
-
- Stephan
-